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VIRTUAL INSTRUMENTATION SYSTEM AND METHOD 

This application claims priority from Provisional Application Serial No. 60/183,374, 
filed February 1 8, 2000, entitled Virtual Instrumeritation System and Method, 
5 Provisional Application Serial No. 60/183,283 filed February 17, 2000, entitled System 
and Method for Virtual Instruments, and Provisional Application Serial No. 
60/181,706, filed February 1 1, 2000, entitled Virtual Instrummt System and Method, 
the entire disclosures of which are hereby incorporated by reference. 

10 Field of the Invention 

The present invention relates to the field of virtual instrumentation, and hardware and 
software for use with the same. 

Background Information 

An instrument is a device which collects data or information firom an environment or 
15 imit under test and displays this information to a user. An instrument may also perform 
various data analysis and data processing on acquired data prior to displaying the data 
to the user. Examples of various types of instruments include oscilloscopes, digital . 
multi-meters, pressure sensors, etc., and the types of information which might be 
collected by respective instmments include voltage, resistance, distance, velocity, 
20 pressure, firequency of oscillation, humidity or temperature, among others. 

Modem instmmentation systems are moving fi-om dedicated stand-alone hardware 
instruments such as oscilloscopes, digital multi-meters, etc., to a concept referred to as 
virtual instrumentation. Virtual instrumentation uses general purpose personal 
computers and woricstations combined with instrumentation software and hardware to 
25 build a complete instrumentation system. In a virtual instrumentation system, a virtual 
instrument (VI) operating on a central computer controls the constituent instruments or 
data acquisition devices from which it acquires data which it analyzes, stores, and 
presents to a user of the system. Computer control of such instrumentation has become 
increasingly desirable in view of the increasing complexity and variety of instruments 
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available for use, and computerized instrumentation systems provide significant 
performance efficiencies over earlier systems for linlcing and controlling test 
instruments. 

The two most popular hardware interface options currently available for 
5 instrumentation systems are IEEE 48 8 -controlled instruments (GPIB instruments) and 
RS-232 controlled instruments. 

The GPIB (general purpose interface bus) began as a bus designed by Hewlett-Padcard 
in 1965, referred to as the Hewlett-Packard Interface Bus (HPIB), to connect their line 
of programmable instruments to their computers. The use of this bus was later 

1 0 expanded to communicate with computers manufactured by companies other than 
Hewlett-Packaid and hence the name General Purpose Interface Bus (GPIB) became 
more widely used than HPIB. The GPB interface bus was later accepted as IEEE 
standard 48 8- 1 975, and has evolved to ANSIAEEE standard 488.1- 1987. In order to 
further improve on this standard, two new standards were drafted, these being 

15 ANSI/IEEE 488.2-1987 and the SCPI (Standard Commands for Programmable 

Instruments) standard. The IEEE 488.2 standard purportedly strengthened the origmal 
standard by removing ambiguities of the IEEE 488.1 standard by defining data formats, 
status reporting, a message exchange protocol, IEEE 488.2 controller requirements, and 
common configuration commands to which all IEEE 488.2 instruments must respond in 

20 a precise marmer. In 1990, the Standard Conunands for Programmable Instruments 

(SCPI) standards were promulgated, which used the cordmand structures defined in the 
IEEE 488.2 standard and formed a single, comprehensive programming conunand set 
that is used with any SCPI instrument. 

A computer can also control an instrumentation system through the computer^ serial or 
25 RS-232 port. There are currently thousands of instruments with an RS-232 interface. 
Moreover, computers can also control instruments using the computer's parallel port. 

Other interfaces and bus protocols are also used in the art. For example. The VXI 

2 
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(VME extension for Instrumentation) bus is a platform for instrumentation systems that 
was first introduced in 1987 and was CMriginally designed as an extension of the VME 
bus standard. 

The wide variety of possible testing situations and environments, as well ais the wide 
' 5 array of instruments available, often make it necessary-for a user to develop a program 
to control respective instraments in the desired instrumentation system. Implementation 
of such systems generally requires the involvement of a programmer to develop 
software for data acquisition, analysis and presentation of instrumentation data. 

Experience and research has shown that current virtual instrument data acquisition 
10 solutions are too complex to be readily usable. Most require extensive knowledge in 
advanced programming and progranmiing techniques, process control, and operating 
systems as well as a comprehensive knowledge of the instruments to be controlled. 
This makes the lead time for putting a system into place very long and expensive. It is 
expensive in terms of development costs, testing, and loss of productivity, 

15 In an effort to cut this lead time, most developers focus only on what is absolutely 

essential in bringing up their system. A direct consequence of this shortsightedness is 
the inability to reuse the solution for other projects and the subsequently higher 
maintenance costs. Upgrades, too, are difficult to incorporate, usually requiring 
extensive rewriting of existing systems. Since these systems were designed for a 

20 dedicated purpose, these changes often introduce flaws that maybe difficult to control. 
Hence, the entire system is compromised. The result is systems that are run at less than 
optimal efficiency and treated with a "hands off" or "if it ain*t broke, don't fix it" 
mentality. This scenario is generally true in research and industry using the currently 
available "off the shelf' products like LabVlEW and HP Vee. 

25 The inventor of the present invention has recognized that popular products such as 
Lab VIEW and HP Vee adopt a graphical user interface ("GUI") without clear 
programming methodology and require a detailed knowledge of programming within 

3 
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their highly specialized enviioriments. Without clear design principles, these products 
fail to be effective as it often leads to poorly written code which is expensive to 
maintain. For instance, GUI programs very often spread over a large number of pages 
and may be several layers of instructions deep. Many times these programs are non- 
5 planar, requiring control lines to cross each other over and over again. As a result, the 
real-world implmientations of these products resemble what is commonly referred to in 
the industry as "spaghetti code". As a consequence, the use of these products result in 
programs which are very difficult to modify, maintain and debug. As such, it may take 
months of training before becoming sufficiently fluent to make even the simplest of 
10 programs and it is very difficult for even the most experienced traditional programmers 
to implement algorithms of even a moderate size that are verifiably rdiable and correct. 
An alternative is to use one of their prepackaged products (e.g. libraries) to control 
intended instruments, but this often constrains the user. 

Summary of the Invention 

15 In accordance with the present invention, a virtual instrument system and method is 
provided which allows the user to mabs immediate use of his or her instrumsats 
without the lengthy process of program development cunently needed in commercial 
products. It is designed to remove the burden of programming from the user and allow 
for nearly immediate use of instruments without learning a new programming language 

20 and a minimal amoimt of coding. 

In accordance with a first embodiment of the present invention, a computerized method 
for controlling at least one instrument coupled to a computer is provided, comprising 
the steps of selecting an I/O interface for communicating with an instmment; inputting 
into a document, as text, a set of vendor- supplied instructions for said instmment; 
25 inputting into the document, as text, a set of values for run time variables for said 

instrument; translating the text in the document into digital signals for communicating 
with the instrument via the I/O interface; and controlling the instrument via the 
translated digital signals, wherein said step of controlling includes one or more of the 
steps of transmitting commands to said instrument and receiving data from said 
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instrument and transmitting commands and data to said instrument. In accordance with 
the present invention, the steps of irputting a set of values for run- time variables, 
translating the text, and controlling the instrument can be perfomied sequentially or 
concurrently. In this manner, it is possible to alter the values of the run-time parameters 
5 "on the fly" during the execution of an experiment or test without stopping and 
restarting program execution. Preferably, the method is implemented using shiared 
memory for storing at least the set of values for run-time variables. The method can be 
used to control both input-data-type instruments such as digital multi-meters and 
output-data-type instnmaents sudi as D/A converters. 

10 In accordance with a second embodiment of the present invention, a method for 

controlling at least one instrament is provided which includes the steps of : a) creating a 
shared memory; b) selecting an I/O interface for communicating with an instrument; c) 
inputting into a document, as text, a set of vendor-supplied instructions for said 
instrument; d) inputting mto the document, as text, a set of values for run time 

15 variables for said installment; e) storing the text of the document in the shared memory; 
f) accessing the shared memory and translating, with an interpreter, the text of the 
document into digital signals for communicating with the instrament via the I/O 
interface; g) controlling the instrament via the translated digital signals. 

For a input-data-type instrument, step (g) includes transmitting commands to said 
20 instrument and receiving data from said instrument, and the method proceeds to: h) 
store the data receiving from the instrament in a second shared memory, i) access the 
second shared memory, and process the data contained therein with a service routine; 
wherein at least steps c through i can be performed sequentially or concurrently. 

For a output-data-type instrument, step (g) includes transmitting commands and data to 
25 said instrament, and accessing a second shared manory to obtain data to transmit to 
said instrament; and the method proceeds to: h) write data to be transmitted to the 
instrument to the second shared memory with a service routine; wherein at least steps c 
through h can be performed sequentially or concurrently. 

5 
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Preferably, the method in accordance with the present invention is implemented using 
an event driven architecture such as IPC. The use of such an architecture improves • 
reliability by reducing the lilcelihood that an run-time error, for example in the 
interpreting process will cause the rest of the appUcation to crash, 

5 In accordance with further aspects of the first and second embodiments, a computerized 
method is provided for controlling a plurality of instruments, and a plurality of 
documents are generated, each document including, as text, a set of vendor-supplied 
instructions for said instrument and a set of values for run time variables for said 
instrument. In accordance with this embodiment, a respective interpreter is provided 
10 for each instrument, and each interpreter executes as a separate thread in an event 

driven architecture. The use of this architecture will, for example, reduce the likelihood 
that an run-time error jfrom one instrument will affect processing of the remaining 
instruments. 

In accordance with other aspects of the jfirst and second embodiments, the step of 
15 inputting a set of run time variables further includes the steps of creatmg, with a 

graphical user interface, a run-time window, the run-time window including input fields 
for entering each of the values for the run-time variables and writing said set of values 
for the run- time variables into said document. 

In accordance with other aspects of the fnst and second anbodiments, the instrument 
20 comprises at least one embedded device and at least one dovmstream device, the at least 
one downstream device being coupled to the I/O interface via the embedded device. . 
The embedded device communicates with the I/O interface via a LAN or WAN, and 
most preferably communicates with the I/O interface via an Internet protocol In this 
regard, both the I/O interface and the embedded device preferably include network 
25 interface cards to support this communication, and most preferably, the embedded 

device is programmed to commimicate usmg TCP/IP protocol. The embedded devices 
may be coupled directly to the I/O interface via the LAN or WAN, or, alternatively, 
may be routed through an intermediate controller. 

6 
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Brief Description of the Drawings 

Figure 1 shows an illustrative virtual instrument system in accordance with an 
embodiment of the present invention including a DAQ system, an oflF-the-shelf 
5 instrument, and an embedded instrumoit. 

Figure 2 shows a flow chart for a main program of the DAQ system of Figure 1 . 

Figure 3 shows a main graphical user interface (GUI) for the main program of Figure 2. 

Figure 4 shows a GUI for a run-time control window for providing the run-time 
controls of Figure 2. 

10 Figure 5 shows a GUI for a plotting routine of Figure 2. 

Figure 6 shows a GUI for a PID routine of Figure 2. 

Figure 7 shows a GUI for a Data Analysis routine of Figure 2. 

Figure 8 shows a parallel port embedded device module in accordance with a preferred 
embodiment of the present invention. 

15 Figure 9 shows a DIO embedded device module in accordance with a preferred 
embodiment of the present inventioii. 

Figure 10 shows a DAC embedded device module in accordance with a preferred 
embodiment of the present invention. 

Figure 1 1 shows an ADC embedded device module in accordance with a preferred 
20 embodiment of the present invention. 

7 
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Figure 12 shows a Serial Port embedded device module in accordance with a preferred 
embodiment of the present invention. 

Figure 13 shows a GPIB embedded device module in accordance with a preferred 
embodiment of the present invention. 

5 Figure 14(a) shows an embedded device controller in accordance with a preferred 
embodiment of the present invention, coupled to a plurality of embedded devices. 

Figure 14(b) illustrates the relationship between various application programs residing 
on the embedded device controller of Figure 14(a). 

Figure 15 shows an illustrative system providing client computers with remote access to 
10 a plurality of devices via a D AQ computer. 

Figure 16 shows an illustrative system providing client computers v^dth remote access to 
a plurality of devices via an intermediate controller. 

Detailed Description of the Preferred Embodiments 

15 The preferred embodiments of the present invention will now be described in detail 

with reference to Figures 1 through 16. Although the system and method of the present 
invention will be described in connection with these preferred embodiments and 
drawings, it is not intended to be limited to the specific form set forth herein, but on the 
contrary, it is intended to cover such alternatives, modifications, and equivalents, as can 

20 be reasonably included within the spirit and scope of the invention as defined by the 
appended claims. 

Overview 

The present invmtion provides a reliable, robust, versatile, yet simple solution to data 
acquisition and process control. Event driven programming makes the DAQ systan in 
25 accordance with the preferred embodiments of the invention easy to install and run. 

8 
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The system provided allows the user to concentrate on commanding and controlling 
devices rather than spending time on authoring narrowly focused complex programs. 

In accordance with the present invention, a DAQ system is provided which is 
comprised of a "software suite" of several independent programs (or processes) running 
concurrently on a computer in a multitaslcing environment, with each process con- 
trolling a specific aspect of the data acquisition and analysis. Preferably, many of these 
programs can be run in stand-alone mode for ease of development and testing. 
Coordination of the concurrently running programs is achieved through a combination 
of shared memory, FIFOs (First-In First-Out) and IPC (Inter-Process Communication), 
which are overseen by the user through GUI (Graphical User Interface). 

The user interface is a unique paradigm in DAQ (data acquisition) and analysis. It 
allows the operator to automatically start up hardware, initialize all the various 
processes of the system, easily navigate the states of the online system, and ihonitor the 
progress of the runs. Comprehensive graphical display of the user interface identifies 
15 all aspects of DAQ that a researcher typically employs. The GUI puts in easy reach 

(typically one click) data analysis, device commanding, data logging, data visualization, 
and process feedback controls. 

Built-in analysis features provides a spreadsheet-like interfece and include multi-axis 
plots of data traces, comprehensive uni-variate and multi-variate statistical functions, 
20 advanced mathematical functions, and signal processing. 

The exemphfied software suite can run on any IBM-compatible PC's with 486 CPU or 
better under MICROSOFT® WINDOWS® 95, 98, 2000 and NT operating system, and 
can be written in a visual programming environment (using such object-oriented 
languages as Delphi and .C-H- Builder). It should be noted, however, that systems in 
25 accordance with the present invention can also be constructed for use with other 

operating systems, such as UNIX, SOLARIS, LINUX, MAC OS, etc., and using other 
programming languages. 

9 
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1. Macroscopic vs. Microscopic Approach 

The preferred system in accordance with the present invention has been carefully 
engineered to address most of the above-mentioned deficiencies in the prior art. A 
philosophical decision was made to implement in the software suite an architecture 
5 which is very similar architecture which is fouad in the hardware of an IBM-compatible 
PC. - . 

From the view point of customers, the basic building blocks of such PC hardware are a 
general-purpose motherboard and a few plug-in cards useful to specific applications. 
. -On the other hand, individual chips and wires coimecting those chips are the building 

10 blocks fl-om the yiew point of manufacturers. While manufacturers inevitably take a 
microscopic approach to build the rnotherboard and/or a plug-in card by assembling 
chips and wiring them, customers take a different approach when theypurchase and 
customize their own computer units. What matters to a customer is this task (or 
fiinction) assigned to each card. Structural details of each card are ignored. A customer 

1 5 simply buys any card which is capable of performing a specific task (e.g., hard disk 
controller, soimd or modem cards), plugs it into any empty slot of the motherboard, 
and it works immediately. 

One of the advantages of IBM architecture.lies in the fact that a customer can take such 
a macroscopic ^proach. One of IBM's major contributions was to organize the basic 
20 computer concepts, and quality control well known in the world of their bigger 
machines and apply them to the microcomputer. IBM successfully introduced a 
hardware architecture whose basic building blocks are not microscopic chips 
but, rather, macroscopic tasks (or cards). 

There is a fundamental difference between these two approaches. Using a microscopic 
25 approach, an individual should buy many chips and wire them carefully to build a card. 
Each chip has specific input and output pins which can be understood only after one 



10 



wo 01/59406 



PCT/USOl/04277 



carefully reads through each chip's data sheet. It may take several days for a reasonably 
skilled expert or hobbyist to build even a simple card. This approadi requires a 
hardware creation process which is complex, lengthy and expensive. Moreover it is 
very difficult to debug if any human en-or occurs. However a macroscopic approach is 
5 free from such a hardware creation process. As a result, it is simple, fast and 
economical. It does not require any debusing process. 

When apphed to a construction of a DAQ software suite, the choice of building blocks, 
results in a similar difference in resulting structure. In a microscopic qiproach, the . 
following correspondence (or similarity) between hardware and software architecture 
10 can be seen: 

Chip Object 
Wiring Line Drawing 

In contrast, a macroscopic approach results in the following conespondence (or 
similarity) between hardware and software architecture: 
15 Motherboard Structure 

CPU Main Program 

Memory Shared Memory 

Clock 4& Interrupt IPC Message 

Keyboard Script File 

20 Plug-in Card Task (Function) 

Hardware Interface User Interface 



It is this similarity which motivated development of the DAQ software suite in 
accordance with the present invention. In the following it will be shown that the 
resulting software provides many advantages over existing DAQ software suites such as 
25 LabVIEW and HP Vee. 

i) The Microscopic Approach as Used in the Prior Art DAQ Systems 
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In the graphical programming solutions used in Lab VIEW or HP Vee, the primitive 
building blocks are objects which create, analyze, or display the data. A diagram is 
created using objects and lines during program creation process. The lines primarily 
represent data and execution flow typically follows the data flow: All the objects have 
5 input and output pins. These pins are used to create subroutines (User Functions or 
VI's) by connecting to pins of other objects through lines. Therefore, lines representing 
data can either be inputs to the object or outputs from the object. These pins are also 
used to sequence data or execution flow. 

This approach is very similar to the one adopted in circuit design. Unfortunately, too 
10 few progranmiars have the experience with the circuit design techniques within this 
approach. The foliowings are some of the most common diflBculties encoxmtered by 
user's while using such an architecture: 

The programmer has to select proper objects from among 
numerous objects given in the pull-down or pop-up menus. 

15 • In many cases, the objects utilized would require hundreds of 

lines to be drawn. Ofl:en times, many of the lines must cross over 
each other repeatedly As a result, a multi-layer window scheme 
is often required. 

It is very difficult, even for the author, to da-ive the execution 
scheme from the interface. The finished diagram can not be 
easily inteipreted by either the author or other programmers. 

As a result, the program creation process is extremely complex. 

ii) the Macroscopic Approach in Accordance vnUx the Present Invention 
In accordance with the present invention, a system is provided which offers very 

12 



BNSOOCID: <WO ^0159406A1_L> 



20 



wo 01/59406 



PCT/llSOl/04277 



different solutions to graphical programming. The primitive building blocks are 
structure and tasks. Tasks are properly arranged within the structure so that data flow 
and execution sequence are automatic. The following software design principles were 
ernployed in order to decide the structure, the nature of each task and the arrangement 
5 of all the tasks within the structure. 



General Programminp ; PrinriplRg 
1 . The software should not require any compiler and should be fully 
open to the user at any level. However it should have all of the 
capabilities of any full-featured compiler. 

10 2. The software should proyide high level graphics in addition to 

math, instrument control, general purpose I/O, and data 
acquisition capability. 

3. The programming should be event driven. Sequence, looping 
and flow of control are natural features of all the modem event 
15 driven languages. 



Structure-related principles 

1. The structure should be simple enough to impose virtually no 
programming work on the user. It should be intuitive aiough to 
allow the user to ascertain its state at a glance. It should be well- 
organized enough to allow an automatic data flow and execution 
sequence. 

2. The structure should have an input for each input-data-type 
instrument (such as A/D converter or DMM) and an output for 
each output-data- type instrument (such as D/A converter). In 
addition, the structure should provide a bridge between input- 
date-type and output-data-type instruments. The bridge is useful 
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for programming, for example, user functions such as PID 
(Proportional, Integral and Derivative) routines. 

3. The structure should allow the user to control any type of 
instrument. Theiefore tight coijpling of instrument-specific 
commands with the remaining program should be avoided. In 
this regard, it is preferable that the instruments commands not be 
"hard coded" into the controlling software. 

4. The structure should maintain shared memories to provide the 
ability to share data among different tasks. Such memories 
should be iinplemented via DLL's (Dynamic Link Libraries). 

5. Since tasks need to communicate with each other to synchronize 
all the concurrently running tasks or to event/time trigger other 
tasks, the structure should have PC. 



Task-related Principles 

1 . There should be a sufficient, but minimal number of taslcs, in 

order to economically include all the possible laboratory-related 
20 human activities. 



2. All the tasks should have visual representation. The user in- 
terface of the task must be famiUar to the customer, using natural 
metaphors. 

3. Special tasks should be provided which allow remote monitoring 
25 and controlling. As a result, one can remotely access the system 

to either query the state of experimental runs or to perform any 
commanding of instruments. 
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4. 



At least one special task should be provided which can 
dynamically set some parameters for the preselected instructions. 



5 



5. 



There should be one special task performing the role of 
interpreter, i.e., a script language to include the ability to evaluate 
conditional statements, case statement, iand loops. 



The implementation of the above-referenced software design principles will now be 
explained in the context of actors, process, interprocess communication, process 
manager, and services, 

ACTORS (instruments) are scripted by users with their configuration, control, and 
10 termination sequences of instructions. In scripting the actors, the user will employ 
those commands commonly in use for generally available interface cards (e.g. GPIB) 
and those specific to his or her device in order to command the behavior of the 
equipment. The user will enter these instructions via a common spreadsheet-like user 
interface which facilitates understanding, reliability, correctness, and ease of use. 

15 PROCESSES are the runtime instances of the actors having the responsibility 
of either collecting data from or issuing conmaandsto the associated instrument. 

INTERPROCESS COMMUNICATIONS (IPC) is the means by which an actor is 
signaled to perform its designated role within the data acquisition context defined by 
the user and the vehicle by which it shares the related data 

20 PROCESS MANAGER is a process responsible for the simultaneously managing and 
providing the timing of information, availability of information, sigaaling of processes, 
and runtime services for the user. 

SERVICES are those tasks that provide for the data analysis tools, data visualization 
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(plotting), logging, enabling/disabling of instruments, and overall control of the cuirent 
data acquisition run. 

Figure 1 shows a DAQ system 1 in accordance with a preferred embodiment of the 
present invention. Figure 2 is a flow chart for amain program 100 for the DAQ system 
5 1, which shows the schematics of structure and tasks as well as interprocess com- 
munication among processes and data stream. 

Referring to Figure 2, the DAQ system 1 includes an interface 105 for communicating 
with input-data type instruments (such as a digital multi-meter) and an interface 109 for 
communicating with output-data type instruments (such as a D/A convater). Data 

10 acquisition and processing for the input-data type instruments is controlled via 
component set 1000 and data acquisition and processing for the output-data-type 
instruments is controlled via component set 1001, with components 107, 120, and 121 
serving both input and output data type instruments are described below. Although the 
invention is described herein as providing with ability to control both input-data-type 

15 and output-data-type instalments, it should be apparent that a system could be 

constructed to control only iaput-data-type instruments (by employing only component 
107 and component set 1000) or only output-data- type instruments (by employing only 
component 107 and component set 1001). 

Referring to Figure 2, four shared memories 201-204 are implemented via DLL'S, and 
20 permit several WINDOWS® applications to share data and provide all the services 

described below. Moreover, the shared memories may also be used to bridge the input 
and output-date-type by providing a temporary buffered layer. In this regard. Figure 3 
shows a PDD control window, where the PID routine 120 of Figure 2 bridges two shared 
memories 201 and 202, allowing data received &om an input-data-type instrument to be 
25 used to control an output data-type instrument. 

The Main Program 100 of Fig. 2 performs six major functions. 

2. Register instruments by user-defined device and channel names, together 
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with types of the hardware interface which the user wants to use (e.g., 
GPIB, RS232 or parallel port). The Device Registration component 107 
in Fig. 1 works as a process manager, maintaining timing and 
synchronization of all the events, in addition to device registration. 

Provides a spreadsheet-lilce interface 302 (See Figure 3) in which the 
user can type in vendor-supplied instrument-specific instmctions 
including commands and run-time values during the initial design phase. 
The run-time values are automatically copied into one of two shared 
memories (Shared Mem DLL 203 or 204) and can be accessed by any 
client program (Acquisition Routines 106 or 108 of Fig. 2), Drag-and 
drop operations of graphical icons from the menu bar 301 into the 
spreadsheet 302 allows the user to construct a runtime-control window 
for controlling the run time values by collecting and rearranging such 
icons in a separate window. Figure 4 shows such a runtime window. 
These runtime controls are associated with the actors (instruments) by 
one or more of shared memories 201 (for controlling processing of data 
received from input-data-type instruments), 202 (for controlling 
processing of data to be sent to output-data-type instruments), 203 (for 
controlling run-time values to input-data-type instruments), and 204 (for 
controlling run-time values to input-data-type instruments). 

Create and maintain four shared memories 201-204 which can be used to 
provide the ability to share data among different processes. For 
processing data received from an input-data-type instrument, the user 
can access data residing in shared memory 201 in order to get services 
110-115 such as plotting 111, printing 1 12, file saving 113, data analysis 
114, DDE to Spreadsheet 115, and To Network 110. As an example. 
Figure 5 shows a chart where three signals are plotted with three 
different Y-scales using the plotting routine 111. For processing data to 
be transmitted to an output-data-type instrument, the user can access 
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data residing in shared memory 202 in conjunction with services From 
Network 116, Keyboard 1 17, Disk File 118, and DDE to Spreadsheet 
119. This architecture not only simplijBes data access, but also prevents 
the user from having to code various file-buffering schemes. All the 
service routines in Fig. 2 are replaceable by user-supplied routines. 

Maintain standard service routines (e.g. plotting 111, printing 113 and 
file saving 113) and register user-supplied service routines (eg. data 
analysis 1 14, network 1 10 and.DDE 115 (Dynamic Data Exchange)) in 
the menu area. 

Define and register user-supplied IPC messages. Object-oriented 
programs are very chatty by nature, frequently sending messages 
between different objects. The Main Program 100 monitors timing and 
synchronization of such event/timer triggered windows messages. All 
the service routines can inherit (or share in) the currently active IPC 
messages. The IPC messages in Fig. 2 represent event/timer triggered 
windows messages. The user-supplied service routines (e.g. 114 and 
1 1 5) can easily share in the currently active IPC message system by 
registering such messages in the routine using standard Windows API 
functions. 

Each client, whidi is a separate executable program with a separate 
thread, and which is designated as Acquisition Routines 106 (for 
retrieving data from input-data-type instruments) and Acquisition 
Routines 107 (for sending data to output-data-type instruments), shares 
instrument specific instructions with the Main ProgramlOO via shared 
memories 203 and 204 respectively and issues commands to the 
associated instrument by translating these instructions into machine 
language. It maintains a software handshake with the 'Main program' by 
exchanging IPC messages. The data acquisition routines 106 and 107 
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automatically interpret the commands typed in the spreadsheet 301 in 
view of the run-time control values stored in shared memory and 
translate them into machine language. Each process in this software will 
automatically acquire a different thread. 

5 In accordance with the preferred embodiment of the present inventioii described above, 
a user can create and run an experiment via virtual instrumentation by simply 

1 . registering the desired instruments and selecting the type of hardware 
interface to be used to commimicate with each instmment; 

2. t3^ing in a set of vendor-supplied instructions in a spreadsheet, 

10 3. rearranging some graphical icons to form a runtime control window, 

4. selectmg a proper client (106 or 108) based on the hardware interface chosen 
and simply run it, and 

5. running service routines by mouse-clicking the corresponding menus. 

Everything else is automatically taken care of by the software. As a result, it takes a 
15 relatively .short a time to program sophisticated instruments. For example, a digital 
multi-meter (DMM) can be configured and run in less than 4 hours. 

The manner in which the DAQ system of Figures 1-7 operates will now be discussed in 
detail. Figure 3 shows the graphical user interface 300 (GU^ for the main program of 
Figure 2. Field 305 lists five devices (e.g. instruments) as currently registered in the 
20 DAQ system: input-data-type devices Devi through Dev3, and output-data-type devices 
Dacl and Dac2. Field 306 allows a user to monitor data transfers through hardware 
interfaces 105 and 109. When the switch in field 306 is in the "on" position, the 
receiving data field will flash when data is transferred through interface 105 and the 
transmitting data field will flash when data is transferred through interface 109. 

25 

Spreadsheet-like interface 302 is shown in Figure 3 for Devi. The corresponding 
interfaces 302 for Dev2, Dev3, Dacl, and Dac2 are hidden from view, but are 
accessible by "clicking" on tabs 311-314. In Figure 3, the interface 302 for Devi 
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contains command lines 1-17 which are used to control a Digital Multi-meter (DMM) 
via a GPEB communications protocol supported by the DMM. As one of ordinary sicill 
in the art will appreciate, user manuals for such DMM's include detailed instructions 
regarding the specific command protocols which must be used to commimicate with the 
5 device via each particular supported interface protocol (e.g. GPIB, RS232). In order to 
initialize Devi, the user simply types the appropriate commands into the spreadsheet- 
like interface 302. 

In the interfece 302, column 3 15 provides the line number and column 316 indicates if 
the instruction at that line number is an internal information instruction (i), a device 

10 setup instruction (s), a device write instruction (w), or a device read instraction (r). 
Column 317 indicates the type of GPIB instruction listed, wherdn "info" indicates a 
post-processing command which is executed after the data is received from the device; 
ibwrt indicates a GPIB write command, and ibrd indicates a GPIB read command. 
Column 318 includes the manufacturer-designated GPIB commands for controlling the 

15 DMM. In this regard, variable parameters in the comrnand are surrounded by "$". 
Column 319 includes the variable parameter field for the instructions (e.g. $xO$ 
through $xS$) , and column 320 includes an initial value for each variable parameter. 

In the example shown, the DMM has been set to provide data on channels 1 through 5 
in scanner mode (line 1 10), with three channels reading resistance (line 5), and two 

20 chaimels reading voltage (line 8). Variable control parameters are provided for 

selecting which channels will read resistance and which channels will read voltage. 
Additional variable control parameters are provided in lines 6 (NPLC) , 7 (Average), 9 
(NPLC), and 10 (Average) for other DMM specific instructions. Initial values for the 
control parameters appear in column 320, with, for example, DMM channels 1, 2, and 3 

25 initially set to read resistance and DMM chaimels 4 and 5 initially set to read DC 
voltage. 

Colmnns 321 and 322 are used to provide run-time controls for the DMM. These run- 
time controls can be varied at any time, and allow the user to reconfigure the DMM "on 
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the fly" without re-starting or otherwise stopping execution of the program. Column 
321 provides a label for the run-time control. In order insert a label, the user "clicks" 
on the label button 334 in menu bar 301, and then types in the desired label. In Figure 
3, the label "Ave No" has been inserted at line 1 to indicate that the value in column 
5 322 is the number of data values that the program will average jfrom each DMM 
.channel; the label "channels" has been inserted at line 5 to indicate that the values in 
colunm 322 list the DMM channels which will read resistance, the label NPLC has 
been inserted at line 6 to indicate that the value in colunon 322 is the NPLC value for 
the resistance measurements; the label "average" has been inserted at line 7 to indicate 
10 that, for resistance measurements, the DMM will transmit the average of three 

resistance measurements to the interface 105; the label "channels" has been inserted at 
line 8 to indicate that the values in column 322 list the DMM channels which will read 
DC voltage, and ftie label NPLC-has been inserted at line 9 to indicate that the value in 
column 322 is the NPLC value for the voltage measurements. 

15 In order to insert a run-time variable field into column 322, the user "clicks" on one of 
the buttons 323-333, 335, 336 in menu bar 301. In this regard, for example, button 328 . 
allows the selection of an integer on a sliding scale (as shown in line 7), button 335 
allows the listing of a combination of elements (as shown in lines 5 and 8), button 331 
allows the listing as a "spinning" integer (as shown in line 1), and button 332 allows the 

20 listing of a "spinning" fraction (as shown in lines 6 and 9). In the example shown, it 
should be noted that the run-time values have been altered from the initial values, and 
that now, for example, DMM channels I, 4, and 5 are reading resistance, while DMM 
channels 2 and 3 are reading DC voltage. 

The labels and run-time values of columns 321 and 322 can also be moved into a "run- 
25 time window" as illustrated in Figure 4. In order to create a mn-time window, the user 
"clicks" on the edit button 337, selects "duphcate" (not shown), and the labels and run- 
time values of colunms 321 and 322 are copied into the run-time window of Figure 4, 
where the user can arrange them on the screen as desired, fa Figure 4, the Devi labels 
and run-time values are arranged in the center column, with the labels and run-time 
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values for Dev2, Dev3, Dacl, and Dac2 shown in tlie side columns. It should also be 
noted that service routines, such as routines 110 through 121 may also be copied into 
the run-time window of Figure 4. 

To begin an experiment, a user clidks on the start button 350. Referring again to 
5 Figures 1 and 2, the run>time values from the spreadsheet-like interface 302 are copied 
to shared Mem DLL 204. Any run-time changes to the run-time values are immediately 
copied to Shared Mem 204 so that tlie values in shared memory are always up to date. 
Acquisition routine 106 (which can be a script interpreter or a compiled routine) reads 
the commands 318 from the interface 302, and the run-time values from the Shared 
10 Mem 204, and generates a command stream to the hardware interface 105, thereby 
controlling the DMM and reading flie requested voltage and resistance data in 
accordance with the designated run-time values. The data received from the DMM 
through the interface 104 is then stored in Shared Mem DLL 201 for ftirther processing. 

In one embodiment, a filter script filters the data received from the interface 105 so 
15 that it is stored in the Shared Mem DLL 201 in usable format. For example, in many 
cases, temperature data received from a DMM is received in Ohms. The filter script 
program could be used to convert the data from Ohms to °C. In addition, the filter 
script program could be used to provide other internal processing. For example, line 1 
of spread-sheet like interface 302 contained an instruction to take the average of every 
20 three values received from the DMM as the actual value. This type of function is 

useftil, for example, for synchronizing the values for devices with different sampling 
speeds. For example, referring to Figure 2, if Devi is three times as fast as Dev2, then 
the devices can be synchronized by setting the run-time control value in line 1 of 
spread-sheet lilce interface 302 to 3. The filter script program 205 could be used to 
25 implement this function. Alternatively, a compiled data filter, as described below, 
could be used. 

The values in Shared Memory 201 are accessible by service routines 1 10 through 121 
as described above. Figure 5 shows an illustrative plotting routine 1 1 1 which has been 
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configured to display channels 1, 2, and 4 as a function of time, with the values of the 
channels plotted on three separate Y axis 401, 402, 403. Figure 6 shows an illustrative 
proportional, integral, derivative (PID) routine 120 configured to receive data from 
channel 4, The output of the PID routine 120 is then available for use as output data for 
5 an oulput-data-type instrument such as a D/A converter. Figure 7 shows an illustrative 
Data Analysis routine 1 14, which tabulates the data received in the fonn of a spread 
sheet and allows the user to configure the data into graphical form as desired. Referring 
to Figure 2, the plotting routing 111 can be accessed via pull down menu 360, the data 
analysis routine 114 can be accessed via pull down menu 362, and the PID routine 120 
10 can be accessed via pull down menu 361, 

The implementation for the ou^ut-data-type instruments such as Dacl and Dac2 
(Digital to Analog Converters) and for Dev2 and Dev3 in Figure 3 is similar to the 
implementation for Devi described above. Each of these devices is controlled by a 
respective acquisition routine 106 (in the case of Dev2 and Dev3) or 108 (in the case of 
15 Dacl and Dac2) which runs on a separate thread. Communication is synchronized by 
the main program using an event driven technology, which, in the illustrated 
embodiment is IPC. However, in the case of output-data-type instruments Dacl and 
Dac2, the available service routines are routines 1 16 through 121. 

Compiled Data Filter 

20 As mentioned above, as data is streaming from the connected input devices 2 and 
instruments 4 into the DAQ system 1, it is captured at interface 105 and stored in a 
shared memory DLL 201. At the point of capture, however, that data may not be in a 
format which is directly usable by the system 1 . Therefore, in certain embodiments of 
the present invention, a filter could be provided which converts the raw data stored in 

25 the shared memory DLL 201 into a format which is compatible with the system 1 . 
Therefore, in certain embodiments, the software of the system 1 includes an option 
which allows the user to load a software filter of his creation for use by system 
software. Preferably, the software filter is in the fomi of a DLL, and the system 
supports the creation of such filter software in, for example, C++ or Pascal. IPC signals 
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the arrival of data in the shared memory DLL and the data filter retrieves the data jfrom 
the shared memory DLL and sends it to routines 110-1 15, 120, 121, To support the 
creation of software filters in these languages, corresponding Win32 capable Integrated 
Development environments that use the gcc and ^c free-ware compilers can be 
5 provided. Software templates and examples for creating a custom filter can also be 
provided to assist a user in creating a software filter in the form of a filter DLL. 

Preferably, the system also includes an option which allows a user to sunply .specify the 
incoming data's format and any conversion formula that should be used on the data. 
Based upon this information, the system can automatically generate a new filter DLL 
10 and insert the filter between the shared memory DLL and the remainder of the system 
software described with regard to Figure 2. 

The system can also include a library of filter DLLs for a set of popular instruments, 
and provide a function automatically detects the instrument 2 that is being used, and 
selects the appropriate filter DLL from the Ubrary. 

15 Embedded Device Technology 

Referring again to Figure 1, in accordance with further embodiments in accordance 
with the present invention, the actois (or instruments) may include embedded devices 2 
as well as currently-available off-the-shelf instruments 4 (such as DMMs) . In 
accordance with this embodiment, a device 2 includes various I/O ports 3 for receiving 

20 unprocessed information such as voltage, resistance, pressure, strain, flow, TC, or 
digital data stream from a downstream source such as a ttiennometer, resistor, 
communications receiver, etc. Embedded in the memory of the device are associated 
device drivers for receiving the information from each input and converting it to digital 
form, an operating system configured to support an P protocol such as TCP/IP or 

25 UDP/IP, an Ethernet adapter, and dedicated software which transmits the digitized 
input through IP protocol to the .DAQ 1 in response to commands from the DAQ 
system 1 . The embedded device may function as either or both of an input-data-type 
instrument or an output-data-type instrument. Referring to Figuro 2, in the context of a 



24 



wo 01/59406 



PCT/USOl/04277 



system for controlling embedded devices 2, the interfaces 105 and 109 reside in the 
embedded devices, and are controlled remotely fiom the DAQ 1 using, for example, 
TCP/IP. In this context, the I/O interface of the DAQ 1 would simply be a port for 
remotely accessing the embedded devices 2, such as a Network Interface Card. 

5 Figures 8 through 13 illustrate, respectively, six illustrative embedded devices 2: a 
parallel port module 2000, a DIO module 3000, a DAC module 4000, an ADC module 
5000, a serial port module 6000, and a GPIB module 7000. When addressing one of 
these modules, the user enters the commands in the appropriate protocol 317 (e.g., 
GPIB, DIO, parallel port, ADC, DAC, and serial port) for the device in the spread sheet 
10 302. As explained in more detail below, these embedded device modules may be 

connected directly to the computer 1, or maybe coimected to an intermediate controller 
8000, which, in turn, is. connected to the computer 1 . 

Figures 8 thou^ 13 show embedded modules 2000 through 7000 which communicate 
with the computer 1 over a LAN and/or WAN (such as the Internet) via the ethemet 
protocol 2001, usmg TCP/IP. LAN connections can, for example, be implemented 
using conventional lOBASE-T or 100BASE-T coaxial cable. Although the module 
2000 will be described below with reference to the ethemet protocol, it should be 
imderstood that alternative protocols can also be used, including for example, Token 
Ring, FDDI, ATM, SONET, and X.25 protocols. Similarly, althou^ the embedded 
modules will be described as communicating via Internet protocols such as TCP/IP and 
UDP/IP, other protocols could similarly be used, including, for example, IBM's SNA, 
Windows' NetBIOS, Apple's AppleTalk, Novell's NetWare, and Digital's DECnet. 
Similarly, wireless communications links and associated protocols may also be used. 

The modules 2000 through 7000 include a conventional NIC 2002 ('"Network Interface 
25 Card") for receiving and transmitting data via ethemet 2001. Referring to Figures 8-13, 
the modules 2000 though 7000 includes a crystal oscillator 2006, CPU 2005, interrupt 
control 2004, brown-out detector 2020, watch dog circuit 2021, flash memory 2008, 
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SPI 2009, EEPROM (2010 though 7010), RAM 201 1, timer circuitry 2022, UART 
2012, bus controller 2013, latch 2014, and I/O port 2023. These components are 
interconnected in a conventional maimer to allow commands from DAQ 1 received at 
the NIC 2002 via the ethemet to be converted mto the appropriate control and data 
5 signals which aie transmitted to the downstream device, and to allow control and data 
signals from the downstream device to be converted into data to be transmitted to the 
computer 1 via the NIC 2002 and ethemet 2001 . Preferably, the module 2000 includes 
two separate ROMs, shown in Figure 8 as Flash memory 2008 and EEPROM (2010 
through 701 0), so that the progranraiing which is generic to all modules 2000 through 

1 0 7000 is contained in one ROM (preferably Flash memory 2008), whereas the module 
specific programming is contained in a separate ROM, in this case EEPROMs 201 0 
through 7010 contains the modijle specific programming necessary to control the 
parallel port 2017, DIO 3017, DAC 4017, ADC 5017, UART 6017, and GPIB 7017 
communication chips, respectively. Most preferably, the modules 2000 through 7000 

15 are fabricated in a two part constmction, with a first circuit boaid containing only 

components which are generic to all of the modules 2000 through 7000, and a second 
circuit board containing the module specific components and optionally some generic 
components as well It should be noted that although the components 2002-2*023 are 
illustrated as separate components, two or more of these components may be febricated 

20 in a single integrated circuit chip. For example, in a particularly preferred embodiment 
of the present invention, an Amtel ATMegal03 microcontroller provides the oscillator 
2006, CPU 2005, watchdog 2021, flash memory 2008, UART 2012, latch 2014, timer 
2022,and interrupt control 2004 of modules 2000-7000. 

Figure 8 illustrates a parallel port module 2000. Data transmitted from the conq>uter 1 
25 via the ethemet 2001 and TCP/IP protocol is received at the NIC 2002, and is converted 
via CPU 2005 into the proper parallel port control and data signals, which are passed to 
parallel port 2017 through I/O ports 2023, and transmitted to a downstream device. 
SuDoilarly, control and data signals received from a downstream device, are received at 
parallel port 2017, pass through I^O ports 2023, and are converted via CPU 2002 into 
30 the proper TCP/IP ethemet protocol, and transmitted to the computer 1 via NIC 2002 
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and ethemet 2001. These conveisions are implemented in a conventional manner via 
components 2004 through 2023, and therefore, will not be discussed in detail herein. 
Exemplary downstream devices which can be controlled via the module 2000 include 
digital multimeters, printers, scanners, CD Rom drives, ZIP drives, and CNC machines. 
5 As one of ordinary skill in the art will appreciate, the acronym CNC refers to computer 
numerical control machines including, for example, computer controlled latlies. 

Figure 9 shows a DIO module 3000, with similar components to Figure 8 bearing 
identical reference numbers. The DIO module includes a Digital I/O interface 3017 
which transmits and receives digital data. In the embodiment shown, the DIO module 

10 3000 transmits and receives 22 bits of data, with 8 bits dedicated to input, and the 

remaining 14 configurable as either input or output ports. The module can similarly be 
constructed to support greater or fewer bits, for example, 2, 8j 16, or 32 bits. In 
addition, the module 3000 may include one or more trigger lines for triggering reading 
or writing of data through the interface 3017. Exemplary downstream devices which 

15 can be controlled via the module 3000 include input type devices such as digital 
multimeters and line condition monitoring devices such as proximity sensors, limit 
sensors, and output type devices such as relays. In general, the module 3000 can be 
used to control any device that accepts as input high/low logic signals, and can monitor 
any device which generates high/low logic signals. In cases in which the high/low logic 

20 signals does not use the same high/low voltage level as the interface 3017, an 

intermediate device can be used to translate the high/low logic signals to and from the 
appropriate levels. 

Figmre 10 shows a DAC Module 4000 with similar components to Figure 8 bearing 
identical reference numbers. The DAC module 4000 is an output type device which 
25 includes a Digital to Analog converter 4017 which converts digital (binary) data 

received from the I/O port 2023 into equivalent scaled voltages. As an example, a 12- 
bit DAC 4017 programmed to generate analog signal in the range of 0 to 10 volts would 
accept 4096 values (2^12 = 4096), from 0 to 4095, which it would convert into 4096 
analog values from 0 to 10 volts in increments of 10/4095 volts. Exemplary 
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downstream devices which can be controlled via the module 3000 include, for example, 
servo motors, power supplies, current controllers, or any other device which requires 
and analog input control voltage. 

Figure 1 1 shows a ADC Module 5000 with similar components to Figure 8 bearing 
5 identical reference nimibers. The ADC module 5000 is an input type device which 
includes an analog-to-digital converter 5017 (ADC) which converts an analog signal 
into a binary digital value. As an example, a 12-bit ADC 5017 programmed to receive 
an analog signal in the range of 0 to 10 volts would convert a received analog signal 
into 4096 12-bit digital yalues in mcrements of 10/4095 volts, and a 12 bit ADC 

10 configured to convert an analog signal in the range of 0. 1 to 200 volts would convert a 
received analog signal into 4096 12 bit digital values m increments of 200/4095 volts. 
A particularly preferred ADC 5017 is a 12 bit ADC which accepts signals in the range 
of 0.1 to 200 volts, has a sampUng rate of about 200,000 Hz, gain of 2, 20, 200, and 
eight channels, each of which can be configured as single ended or differential. 

15 Exemplary downstream devices which can be connected to this module include any 
device which generates an analog output, including, for example, strain gauges, 
pressure sensors, pressure transducers, torque sensors, photodiodes, or simply a pair of 
wires attached across a voltage potential. 

Figure 12 shows a UART Module 5000 with similar components to Figure 8 bearing 
20 . identical reference numbers. The UART module 6000 is an input and output type 
device which includes a UART chip 6017, or imiversal asynchronous receiver- 
transmitter. tJART 6017 is of conventional construction and includes a transmitter 
section and a receiver section. The transmitter converts bytes of parallel data from I/O 
port 2023 into a serial stream of data bits, and the receiver accepts a serial stream of 
25 data and converts it into bj^es of parallel data which are transferred to the I/O port 
2023. Examples of UARTs include RS 232 transceivers and RS 485 transceivers. 
Exemplary downstream devices which can be controlled via the module 5000 include, 
for example, digital multimeters, scales, amplifier, modems, and CMC machines. 
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Figure 13 shows a GPIB Module 6000 with similar components to Figure 8 bearing 
identical reference numbers GPIB Module 6000 is an input and output type device 
and includes a GPIB chip 7017 which converts data to and from the GPDB protocol 
discussed above. Exemplary downstream devices which can be controlled via the 
5 module 5000 include, for example, digital multimeters, and GPIB laboratory 
instruments in general. 

Figure 14(a) illustrates a system including an intermediate controller 8000 disposed 
between a plurality of embedded modules (in the illustration, modules 3000, 4000, 
5000) and the DAQ 1, and Figure 14(b) illustrates graphically the organization of 

10 programs and sockets on the controller 8000. Litermediate controller 8000 includes a 
NIC 2002 (right side) coupled to the DAQ 1 via a LAN or via the Internet, a NIC 2002 
(left side) coupled to modules 3000, 4000, and 5000 via an ethemet hub 9000. The hub 
9000 could be an extemal hub (as shown), or alternatively, could be incorporated into 
the controller 8000. The controller 8000 is configured as a server, and includes a CPU, 

15 ROM, and RAM memory for transferring information between the computer 1 and the 
modules 3000-5000. Preferably, the controller is implemented with a Linux operating 
system in order to reduce storage requirements, and communicates with DAQl and the 
modules 3000-7000 via an IP protocol such as TCP/ff or UDP/IP. 

At power-up, the controller 8000 transmits a multicast signal to query any connected 
20 modules (3000-7000), Each connected module (in this case 3000, 4000, and 5000) 
responds with a MAC address, which is a hard-coded address ID which is specific to 
the particular manufacturer and model (e.g. ACME Co, DIO module). In any event, 
referring to Figure 14(b), an appUcation program Al running on the controller 8000 
then assigns- a mock IP address to each connected module. In this regard, the IP address 
25 is a "mock" address in that it is not a valid Internet ff address but, rather, is an address 
provided merely for purposes of allowing the controller 8000 to communicate with the 
connected modules via TCP/IP protocol. For example, the controller could designate 
each connected module with consecutive IP addresses beginning with 10,0.0.1, 
10.0.0.2, etc. In contrast, the controller 8000 itsdf has a valid TP address which is 
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fixed by the Internet service provider (BP), This IP address can be obtained b}^ the 
controller 8000 by sending a request for the IP address to the DAQ 1 using, for 
example, the revo-se address resolution protocol (RARP). Alternatively, the IP address 
could be provided to the module by direct data input, for example, via a serial port. 

5 The application program Al then initiates a respective program having a respective 
"socket" (or other software coimection) for each coimected module, so that 
communication with each module is run independently. Application programs Ala, 
Alb, and Ale having sockets si, s2, and s3 are used to provide an independent software 
connection (e.g. thread) between the modules 2000, 3000, 4000 and the controller 

10 8000. The application program Al also initiates an application A2, which, in turn, 

initiates respective programs A2a, A2b, and A2c having corresponding sockets si', s2', 
and s3' for providing an independent software connection (e.g. thread) for 
commrmicating data from the modules to the DAQ system 1. Each of these sockets si', 
s2', and s3' have a corresponding channel in the DAQ system 1, which channels operate 

15 in the same manner as described above. In addition, each socket s (e.g. si, s2, s3) has a 
corresponding buffer a (e.g. al, a2, a3), and each socket s' (e.g. sl\ s2', s3') has a 
corresponding buffer b (e.g. bl, b2, b3). As one of ordinary skill in the art will 
appreciate, a socket is defined as the combination of an IP address and a port number, 
and is used in the TCP/IP protocol to direct data to the appropriate application in the 

20 network. The IP address for the sockets sl-s3 are the mock IP addresses discussed 

above, whereas the IP address for the sockets sT-sB'is the IP address of the controller 
8000. The port numbers for sockets sl-s3 are generated by the program A2. The port 
numbers for the sockets sl'-sB' are preferably assigned by prpgram A2 in accordance 
with conventional lANA assigned "Well Known Port" numbers (e.g., 20 for FTP, 23 

25 for Tehiet, 25 for smtp, and 80 for http). The port number and module type for each 
connected module (2000-7000) is transmitted to the DAQ 1 so that the DAQ 1 
program can identify the connected modules. 

When data is recdved from a module on a socket si, for example, the data is stored in 
buffer al, and an IPC is generated to alert application a2a that data is available to 
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transmit via socket si'. Application a2a then fetches the data from buffer al, and 
transmits it to the DAQ 1 via socket si'. Similarly, wdien data is received for module 
2000 from DAQl over socket sl\ application a2a stores the data in buffer bl, and 
generates an IPC to application ala indicating that data is available. Application ala 
5 then fetches the data from buffer bl, and transmits it to the module 2000 via socket si. 

In accordance with another embodiment of the present invention, the modules 2000 to 
7000 can be directly coimected to the DAQ 1 without the use of a controller 8000. In 
accordance with this embodiment, the mdividual module (2000-7000) is configured to 
communicate over an IP protocol using a valid IP address, assigned, for example, by an 

10 ISP. Preferably, the module is progranuned to communicate to the remote DAQ 1 via 
NIC over TCP/IP protocol. In this regard, an application on the module (2000-7000) 
establishes a socket using the IP address and a designated port. As set forth above, the 
port is preferably assigned in accordance with conventional IAJS!A assigned "Well 
Known Port" numbers. The IP address for the modules can be assigned in a variety of 

1 5 ways, but is preferably obtained by sendmg a request to the DAQ 1 for an IP address 
usmg, for example, the reverse address resolution protocol (RARP). Alternatively, the 
IP address could be provided to the module by direct data input, for example, via serial 
port 2012. 

Remote Capability 

20 The use of the shared memory 201 through 204 allow the data^put-type and data- 
output-type devices to be controlled, during run-time, from remote computers. In this 
regard, referring to Figure 2, the mn-time control values stored in Shared Mem DLLs 
204 and 203 and can be accessed and changed remotely over a computer network as 
indicated by components Network 101 and Networic 104 respectively. Similarly, data 

25 received from an input- type device can be accessed remotely from Shared Mem DLL 
201 as indicated by service routine To Network 1 10. In addition, data to be transmitted 
to an output-type device can be input remotely to Shared Mem DLL 201 as indicated by 
service routine From Network 1 16. The network-related service routines can be 
implemented using object-oriented remote procedure call. To facilitate reliable 

31 



BNSDCXID: <WO ^0l594O6AlJ_> 



01/59406 



PCT/USOl/04277 



machine-to-machine communications, much of the e-mail messaging infrastructure 
provided by the Internet can be adopted. This can be implemented, for example, with 
TCP/IP protocols. Communication over a Local Area Network (LAN) can similarly be 
implemented via Ethemet and the TCP/IP protocols in a conventional manner. 

In accordance with a preferred embodiment of the present invention, a remote 
operations control system (ROCS) is provided to allow users to remotdy administrate 
hardware devices 2, 4, 2000-7000 attached to the system. The remote administration of 
hardware can be.done either directly from DAQ system 1 or through the intermediate 
controller 8000. The implementations and procedures for the ROCS can be subdivided 
into the following categories: 

DAQ System 1 Software Based 

DAQ System 1 Java Based 

Intermediate Controller 9000 Software Based 

Intermediate.Controller 9000 Java Based 

As. indicated above, there are two modes of remote operation: 1) a remote client 
computer which accesses the DAQ system 1 .to control devices 2, 4, 2000-7000 
connected to the system 1; 2) a remote computer which communicates directly with an 
intermediate controller 9000 to control the devices 2000-7000 which are connected to 
the intermediate controller 9000. 

In order to understand the specifics of the ROCS it is helpful to review the underlying 
configuration of an exemplary system and its corresponding components. Such a system 
is illustrated in Figure 15. For the purposes of this example there are three fimdamental 
classes of components that are required for the remote operations control system: 
devices, master control unit, and a client: 

Devices 2, 4, 2000-7000. As discussed above, these are hardware components 
connected to the DAQ system computer 1 (See Figures 1 and 15). These 
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components feed information into the DAQ system l and receive commands 
from it. Examples of the devices include multimeters, wave function generators 
(e.g. devices 4 of Figure l),and the devices 2, 2000-7000 discussed above with 
regard to Figtires 1, 8-13. 

5 Master Control Unit (MCU): This is the computer 1 containing the authoritative 

copy of the DAiQ system software and to which the hardware devices are 
physically connected. This computer acts a s a server to the connecting clients. 
From this computer it is possible to monitor and control the attached devices. 

Clients 5: These are the remote instances of software used to connect to the 
10 Master Control Unit for the purposes of monitoring or controlling the devices. 

The client software cannot act independent of the Master Control Unit in 
interfacing with the devices and must connect to a Master Control Unit in order 
to ftmction. 

To set up a remote operations control network with this configuration (as opposed to 
15 the intermediate controller configuration discussed below), at least one of each of the 
components mentioned above must be present. A device coimects physically to the 
MCU through a hardware interface on the MCU. In this regard, the MCU is a computer 
1 having installed thereon an instance of the MCU DAQ software. The computer 1 can 
interact with the devices throu^ normal commimications as described above with 
20 regard to non-remote operations. However, in addition to this core functionality, 
several additional features are added to allow for remote operations control of the 
devices. To accept remote operations control requests, the MCU is placed in the 
ROCS mode. Once ROCS mode has been established, a listening network socket is 
created on the network interface connected to flie network from v^diich the ROCS 
25 requests will originate. This socket is referred to as a ROCS Authorization Request 
Port. The port listens for a connection to be made to it by one of the cUents. It is 
important to note that while the MCU is in a state to listen for ROCS requests, flie 
MCU itself can preferably still fimction as the control authority over the devices on its 
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network (e.g., from a user entering keystrokes directly into the computer 1). However, 
once controlling authority of one or more devices has been passed from the MCU to a 
cUent, the MCU no longer has active control over those devices, preventing it from 
issuing commands to those devices (although it is able to passively monitor activity on 
5 the system from any and all devices). 

When a cUent computer 5 (e.g. a computer implementing client DAQ software) wishes 
to gain ROCS privileges to the devices, it first makes a request to the ROCS 
Authorization Port. The purpose of this port is two fold. Fiist, the ROCS 
Authorization Port is designed so that only one instance of the GDAQ software (either 

10 cHent or MCU) can control any given device connected to the MCU at any given time. 
If for example client A has authoritative control over device B, the MCU and all other 
cUents will be refiised control privileges over device B xmtil client A has relinquished 
control back to the MCU. Preferably, however, the MCU, by vutue of its master 
authority over the system as a whole, is allowed to remove any remotely connected 

15 users and take control of any and all devices on the network. The second ftmction of 
the ROCS Authorization Port is to verify the identity of the user making the request. 
The schemes used for this authentication can var}' from usemame and password 
combinations to public key cryptosystems and digital signatures or combinations 
thereof. The type of security measures implemented in the system and extent to which 

20 security precautions are talcen are a ftmction of both the network on which the MCU . 
and clients reside and the level of security required by the user. Once the client has 
been verified and it is possible for the control request to be granted by the system the 
connection protocol begins. 

When an MCU detects that an authorized requesting chent can be issued control of the 
25 modules several steps are taken, again many of which depend on the security 

precautions required by the user. Regardless of the security implementation, once a 
chent is given approved by the MCU for control, the MCU allocates a series of ports on 
its network connection. A corresponding port is provided for each device the client 
wishes to interact with. It should be noted that it is not necessary for the dient to have 
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controlling authority over the modules in order to initiate this procedure. For example, 
a client could request, and the MCU grant, the ability to monitor data from the device 
without granting any controlling authority over the device. In contrast to controlling 
authority, multiple clients can be provided with the ability to monitor data fi-om device 
5 at the same time. Monitoring authority can be granted using a similar procedure to 
controlling authority without the ability to send conmiands. 

In a passive security environment, the sockets are allocated for the client's connections 
and the client waits for those connections to be established. For a system with more 
elaborate security precautions, packet filtering rules can be modified to only allow 
10 incoming packets to those ports from IP addresses that match the client which was 
authorized for use on the MCU. In any event, once the security requirements arc met, 
session begins and will continue.to function until either the connection is lost or the 
client or MCU ends the session. 

Incoming data to the client is in the form of statistically averaged data packets at a rate 
1 5 matching that at which the client is connected. Control packets are of a limited data 
size and will be sent over network channels. Therefore, the delay time in transmission 
is the only major factor that should be taken into account when using the system. 
Preferably, the system allows a client to request control of a device on an individual 
basis. In other words, it is not necessary to allocate control of all the devices 
20 simultaneously. This allows other remote clients or the MCU to retain control over 
other devices on the network. The system can also include an option for "an all or 
nothing allocation scheme" in which all devices must be allocated to a single client. 
This option is useful for appUcations in which individual access to devices is dangerous 
(e.g., in an application in which all of the devices relate to closely inter-related 
25 processes). 

As mentioned above, the system preferably allows multiple clients and the MCU to 
concurrently monitor data. This can be initiated by making a monitoring request to the 
MCU Monitoring Request Port. Preferably, this port can be set or removed at the 
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discretion of the MCU operators. In any event, through this port, security measures can 
• either be implemented or ignored as described above with regaid to the MCU 
Authorization Port scheme. This port performs the same allocations as described above 
before allowing any authorized user (or any user at all if there are no security checks) to 
5 have a monitoring port opened to give them access to monitoring the data. Data that is 
segmented off to a shared memory region in the MCU DAQ software can therefore be 
sent not only to the terminal in which it is running (the MCU), but also can be sent from 
that shared memory region to one or all of the sockets connected to a client interface. 
The inclusion of the client sockets on the MCU simply changes the number of targets 
10 for the shared memory region that holds the device data. 

The client software used to interact with the MCU can be implemented in a number of 
ways. For example, client software could be^provided in the form of a compiled 
program ttiat must be installed on the client machine in order to run. This software can, 
in essence, be a limited version of the MCU DAQ software, which does not have the 

15 server utilities. To run, this type of client DAQ software simply needs to be installed 
on the client computer and have a network connection to the MCU. Alternatively, the 
client software could be in the form of a Java applet. In this embodiment, the MCU 
would not only contain the listening sockets and authorization ports, it would also 
contain a port that upon coimection uploads a Java applet on request to a client 

20 computer. The applet sent to the client would be a client version of the DAQ software 
capable of being executed on any machine. This embodiment allows for any type of 
client environment that supports the Java VM. In addition to the GUI interface, a more 
basic text version could be provided to allow interfaces from console based machines or 
even PDA devices. The same type of authorization schemes can be set in place or none 

25 at all, just as in the installable client DAQ software. 

A second example of a remote communication system is one which uses the 
intermediate controllers 8000. Such a system is illustrated in Figure 16. In this 
example, a system includes: 
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Devices 2, 2000-7000: Hardware devices, such as RS-232C, DIO, DAC, and 
ADC modules which transmit and receive their data through a standard network 
interface. 

Intermediate Controller 8000: A piece of software residing on an indq)endent 
5 piece of hardware is coupled to the devices 2000-7000 via the standard network 

interface, and that performs control and data routing to and from the devices 
from the cUents. 

Clients 5 :. These are the remote instances of software used to control the 
modules via the intermediate controller 8000. 

10 In this embodiment, the intermediate controller 8000 is substituted for the MCU as the 
intermediate component between the clients 5 and the one or more devices 2, 2000- 
7000 connected to the intermediate controller 8000. The intermediate controller is 
preferably implemented in a custom built piece of hardware (to minimize its footprint), 
but can also be installed on a conventional computer (such as a PC) that resides on the 

15 same network as the modules. The intmnediate controller 8000 creates and tracks all 
the connections with the devices, and handles all communications between itself and 
the devices 2000-7000 on the network. The intermediate controller 8000 also maintains 
a connection to a network which the clients can access (e.g., the iiteraet, other WAN, 
or even a LAN). The clients make their connections and requests for control of the 

20 devices 2000-7000 through the intermediate controller 8000. In this manner, the 

intermediate controller 8000 acts as a control router for the devices 2000-7000. Similar 
to the MCU, the intermediate controller 8000 can have ROCS Monitoring Request and 
Authorization Ports, and can create listening sockets to handle incoming connections. 
Like the MCU, the intermediate controller 8000 can incorporate a series of security 

25 measures such as usemame / password pairs or public key crjptosystems to ensure only 
authorized users are allowed to connect to the sj^tem and that there is only one user in 
control of a device at a time. In addition, the intermediate controller 8000, lilce the 
MCU, can have the capability to lock out all users or distribute access ri^ts to users for 
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individual modules on a case by case basis at the discretion of an administrator of the 
intermediate controller. 

Unlilce the MCU, however, the intermediate controller cannot, by itself, control the 
devices 2000-7000. With the intermediate controller embodiment, users can only 
5 control the devices 2000-7000 via a client. Althou^ a super user maybe allowed to 
log into the intennediate controller for administrative purposes, the intermediate 
controller 8000 otherwise performs its functions independent of users on the system. 
The intermediate controller 8000 handles all connections to the devices and, through 
the use of statistical fimctions, can distribute data to the connecting clients at rates they 

10 are able to withstand on their connections. Control functions from the clients are 

received by the intermediate controller and routed to the devices for processing. The 
intermediate controller 8000 preferably has the ability to limit the number, type, and 
access of all users connected to it. In addition, packet filtering rules can be set up for 
security reasons and dynamically changed based on authorized incoming user 

15 connections. 

As with the MCU embodiment, there are a number of ways in which a client can 
connect to the intermediate controller 8000. For example, an application program 
written specifically to interface with a module of a specific type can be used. This 
software will make a request to the authorization port if it wishes control of a module or 

20 the monitoring request port if it merely wishes to monitor. In dther case, the dient will 
then go through whatever security measures are in place (e.g. basic usemame / 
piassword combinations, digital keys, or no security at all). Once the control or 
monitoring authentication has been completed, a series of sockets will be. allocated for 
the client to connect to (see Figures 14(a-b)). These sockets will give the dient either 

25 control or monitoring channels for the modules it has requested, assiuning of course it 
has access to them. As with the MCU embodiment, any number of cUents may have 
access to monitor data from any number of devices 2000-7000, with the proper access 
rights, but only one client may have control ova: any given device at a given time. "All 
or nothing allocation schemes" can similarly be supported by the intermediate 
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controller. Control and monitoring can continue from this point until either the 
connection is lost or the client ends his session. Should either one of these events occvir 
cleanup measures and reallocation of control ri^ts will be retumed to the system. 

Similar to the MCU embodiment, the client software for the intermediate controller 
5 embodiment can come in a number of forms. For example, the client software can be 
provided in a compiled program that is installed on the user's computer (the client). The 
client software can then be executed to connect to the interinediate controller 8000 via a 
network connection (such as the Internet, other WAN, or even a LAN). Alternatively, 
the client software can be provided in the form of a Java applet or a Java application. 

10 In accordance with this embodiment, the client may, through the use of a browser, 
connect to a port on the intermediate controller 8000, download the JAVA applet 
therefrom, and then run the JAVA applet through the Java VM on the client computer. 
This embodiment allows for portability over platforms not specifically envisioned by 
system developers, and allows the user to be able to download the client software and 

15 execute it form any computer to which they have access . The intermediate controller 
can also include an option (selectable by the intermediate controller administrator), to 
enable or disable the ability to download the Java applet from the intermediate 
controller. 
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What is claimed is : 

1 . A computerized method for controlling at least one instrument coupled to a 
computer, comprising 

a) selecting an I/O interface for conmiunicating with an instalment; 

b) inputting into a document, as text, a set of vendor-supplied instructions for 
said instrument; 

c) inputting into the document, as text, a set of values for run time variables for 
said instrument; 

d) translating the text in the document into digital signals for communicating 
with the instrument via tiie I/O interface; and 

e) controlling the instrument via the translated digital signals, wherein said step 
of controlling includes one or more of the steps of transmitting conunands to said 
instrument and receiving data from said instrument and transnodtting commands and 
data to said instrument; 

wherein at least steps c, d, and e can be performed sequentially or concurrently. 

2. The method of claim 1, wherein the step of inputting a set of run time variables 
further includes the steps of 

creating, with a graphical user interface, a run-time window, the run-time 
window including input fields for entering each of the values for the run-time variables; 
writing said set of values for the run-time variables into said document. 

3. The method of claim 1, wherein the instrament comprises at least one embedded 
device and at least one downstream device, the at least one downstream device 
being coupled to the I/O interface via the embedded device wherein the 
instrument comprises at least one embedded device. 

4. The method of claim 1, wherein the instrument comprises at least one DMM. 

5. The method of claim 3, wherein said embedded device includes a parallel port 
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interface for coupling to the downstream device. 

6. The method of claim 3, wherein said embedded device includes a DIO interface 
for coupling to the downstream device. 

7. The method of claim 3, wherein said embedded device includes a digital to 
analog converter for coupling to an input of the downstream device. 

8. The method of claim 3, wherein said embedded device includes an analog to 
digital converter for coupling to an output of the downstream device. 

9. The method of claim 3, wherein said embedded device includes a serial port 
interface for coupling to the downstream device. 

10. The method of claim 3, wherein said embedded device includes a GPIB 
interface for coupling to the downstream device. 

11. A system for controlling at least one instrument comprising: 

a) creating a shared memory; 

b) selecting an I/O interface for commimicating with an instrument; 

c) inputting into a document, as text, a set of vendor-supplied instructions for 
said instrument; 

d) inputting into the document, as text, a set of values for run time variables for 
said instrument; 

e) storing the text of the document in the shared memory; 

f) accessing the shared memory and translating, with an interpreter, the text of 
the document into digital signals for communicating with the instrument via the I/O 
interface; and 

g) controlling the instrument via the translated digital signals, wherein said step 
of controlling includes transmittiiig commands to said instrument and receiving data 
from said instrument; 
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h) storing the data received from the instniment in the second shared memory; 

i) accessing the second shared memory, processing the data contained therein 
with a service routine. 

wherein at least steps c through i can be performed sequentially or concun-ently. 

12. The system of claim 1 1 , wherein the instrument comprises at least one 
embedded device and at least one downstream device, the at least one 
downstream device being coupled to the I/O interface via the embedded device 

1 3 . The system of claim 1 1 , wherein the instrument comprises at least one DMM. 

14. The system of claim 12, wherein said embedded device includes a parallel port 
interface for coupling to the downstream device. 

15. The system of claim 12, wherein said embedded device includes a DIG interface 
for coupling to the downstream device. 

16. The system of claim 12, wherein said embedded device includes a digital to 
analog converter for coupling to an input of the downstream device. 

17. The system of claim 12, wherein said embedded device includes an analog to 
digital converter for coupling to an output of the downstream device. 

18. The system of claim 12, wherein said embedded device includes a serial port 
interface for coupling to the downstream device. 

19. The system of claim 12, whereiu said embedded device includes a GPIB 
interface for coupling to the downstream device. 

20. The method of claim 1 1, wherein the step of inputting a set of run tune variables 
further includes the steps of 
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creating, with a graphical user interface, a run-time window, the run-time 
window including input fields for entering each of the values for the run-thne variables; 
writing said set of values for the run-time variables into said document. 

2 1 . The method of claim 1 1 , wherein the service routine is a plotting routine. 

22. The method of claim 1 1, wherein the service routine transmits the data to a 
remote computer over the Internet. 

23. The method of claim 11, wherein the sei-vice routine is a printing routine. 

24. The method of claim 1 1 , wherein the service routine is a file saving routine. 

25. The method of claim 2 1 , wherein the plotting routine plots a plurality of signals 
on a single x-axis and a plurality of y-axes. 

26. A system for controlling at least one instrument comprising: 

a) creating a shared memory; 

b) selecting an I/O interface for communicating with an instrument; 

c) inputting into a document, as text, a set of vendor-supplied instructions for 
said instrument; 

d) inputting into the document, as text, a set of values for run time variables for 
said instrument; 

e) storing the text of the document in the shared memory; 

f) accessing the shared memory and translating, with an interpreter, the text of 
the document into digital signals for communicating with the instrument via the I/O 
interface; and 

g) controlling the instrument via the translated digital signals, wherein said step 
of controlling includes transmitting commands to said instrument, and accessing a 
second shared manory to obtain data to transmit to said instrument; 

h) writing data to be transmitted to the instrument to the second shared memory 
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with a service routine; 

wherein at least steps c through h can be performed sequentially or concurrently. 

27. The system of claim 26, wherein the step of inpiitting a set of run time variables 
further includes the steps of 

creating, with a graphical user interface, a run-time window, the run-time 
window including input fields for entering each of the values for the run-tirrie variables; 
writing said set of values for the run-time variables into said documait. 

28. The system of claim 26, wherein the service routine is a keyboard routine. 

29. The system of claim 26, wherein the service routine receives data from a remote 
computer over the Internet, and writes the data to the second shared memory. 

30. The system of claim 26, wherein the instrument comprises at least one 
embedded device and at least one downstream device, the at least one 
downstream device being coupled to the I/O interface via the embedded device 

3 1 . The system of claim 26, wherein the instrument comprises at least one DMM. 

32. The system of claim 30, wherein said embedded device includes a parallel port 
interface for coupling to the downstream device. 

33. The system of claim 30, wherein said embedded device includes a DIO interface 
for coupling to the downstream device. 

34. The system of claim 30, wherein said embedded device includes a digital to 
analog converter for coupling to an input of the downstream device. 

35. The system of claim 30, wherein said embedded device includes an analog to 
digital converter for coupUng to an output of the downstream device. 
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36. The system of claim 30, wherein said embedded device includes a serial port 
interface for coupling to the downstream device. 

37. The system of claim 30, wherein said embedded device includes a GPIB 
interface for coupling to the downstream device. 

38. The system of claim 30, wherein the embedded device is coupled to the I/O 
interface via a local area network. 

39. The system of claim 30, wherein the embedded device is coupled to the I/O 
interface via a wide area network. 

40. The system of claim 30, wherein the wide area network is the Internet. 

41. The system of claim 39, wherein the embedded device includes a network 
interface card, a memory, and a central processing unit, wherein the I/O interface 
includes a network interface card, and wherein the embedded device 
communicates with the I/O interface via an Internet protocol 

42. The system of claim 30, wherein the embedded device comprises a plurality of 
embedded devices, each coupled to at least one downstream device, and wherein 
the system further comprises an inteixnediate controller coupled between the 
plurality of embedded devices and the VO interface, the intermediate controller 
connected to the plurality of embedded devices via a local area network, the 
intermediate controller connected to the I/O interface via a wide area network. 

43. The system of claim 30 wherein 

the I/O interface includes a network interface card; 

the intermediate controller includes a network interface card, a memory, and a 
central processing unit, the intomediate controller communicating with the I/O 
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interface via an Internet protocol 

each embedded device includes a network interface card, a memory, and a 
central processing unit, each embedded device communicating with the intermediate 
controller via an Internet protocol. 

44. The method of claim 1 2, wherein the embedded device is coupled to the I/O 
interface via a local area network. 



45. The method of claim 1 2, wherein the embedded device is coupled to the I/O 
interface via a wide area network. 

46. The method of claim 1 2, wherein the V/ide area network is the Internet. 

47. The method of claim 43, wherein the embedded device includes a network 
interface card, a memory, and a cmtral processing unit, wherein the I/O interface 
includes a network interface card, and wherein the embedded device 
communicates with the I/O interface via an Internet protocol. 

48. The method of claim 3, wherein the embedded device is coupled to the I'O 
interface via a local area network, 

49. The method of claim 3, wherein the embedded device is coupled to the VO 
interface via a wide area network. 

50. The method of claim 3, wherein the wide area network is the Internet. 

5 1 . The method of claim 47, wherein the embedded device includes a network 
interface card, a memory, and a central processing unit, wherein the I/O interface 
includes a network interface card, and wherein the embedded device 
communicates with the I/O interface via an Internet protocol. 
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